March 1999 Technology Corner

Have you noticed the wealth of applications today that feature Microsoft's Visual Basic (VB) as their scripting and lightweight programming tool? These applications allow users glue together special features of the code into customized programs. IT professionals usually scoff at VB as a development language and do not seem very interested its increasing use as a glue language. They prefer to hang their hats on the muscle tools like C++ and Powerbuilder, while others look to relatively young tools like Java as the silver bullet for new development.

My point here is not to sell the utility of VB. There a larger movement here than picking the right programming tool, and the trend does not depend on it. I do not mean that you can skip programming; the fact that so many applications embed VB indicates that there are more places for programming then ever before. What I am trying to say is that we should stop looking for the do-everything tool.

In today's world of objects, interfaces and powerful compilers, most languages have merged into a relatively homogeneous set with remarkably similar syntax and feature sets. For example, Web applications written using Microsoft's Internet Information Server's Active Server Pages (IIS ASP) can flip-flop back and forth between either VBScript (a subset of VB) or JScript (a subset of Java). Converting code from VB to JScript or vice-versa requires the minimal effort of adding semicolons and braces, and not much more.

This type of flexibility is important because it lets developers select languages and environments that best suit their needs. In IIS ASP's case, VB has better formatting and collection management while JScript has better access to the interpreter. If you can work in VB alone, then it is possible to go one step further and use Microsoft Access97 or Visual Basic, where the debug tools are much stronger, to write and test VB code for IIS ASP.

In other cases, developers may be able to exploit the differences between features of similar programming environments. One tool may be much faster to program but hard to deploy (like Access), another may be easy to deploy but offer fewer features (like Web-based interfaces). Yet another could be powerful but require more development effort and expertise (like Visual Basic).

Technology Background

Multi-tool development is being fueled by the increasing availability of self-contained objects. Recent generations (meaning in the last 15 years) of programming languages flocked to the object-oriented models to make application development faster. These languages did not fulfil their promise as rapid application development tools, however.

The reality is that while complex and highly structured object-oriented languages (like C++) are very powerful, they are often too complex or needlessly powerful for most developers' needs. Even though I am a very strong believer in object-oriented programming, most developers rarely need or use academic object concepts like multiple inheritance, polymorphism, and encapsulation.

Instead, a diluted and simpler (or flatter) object model is pervasive. In this scaled-back model, objects have become self-contained components that generally sit outside the programming environment and provide some sort of minimal interface. These components come in many flavors, such as the public domain CORBA model (common object request broker architecture) or Microsoft's proprietary COM (common object model) definition. These component architectures allow applications to be put together more like Lego towers than elaborate code skyscrapers or cathedrals.

The growing popularity of VB as a scripting language highlights this change. The vendors adopting this approach are converting their applications into collections of components. Hooking these components together does not require special programming languages or learning cryptic commands. Some vendors like Rockwell Software (which sells PLC interfacing software) do not even feature a dedicated GUI environment. Instead they expect customers to build the GUI from components using their choice of tools. Rockwell's competitor, Intellution, is pursuing the same course and actively breaking their powerful OI tools into COM-enabled components.

It's been exciting to see that programmable objects being sold "off-the-shelf" as parts of an application (Intellution) or individually (Rockwell Software). In general, today's object-oriented development has struck a good balance between the powerful features and ease of use.

For companies to get the best value from development efforts, their developers (either internal or external) should be willing to shift from tool to tool to give the best value for their effort. This requires compromise from both the developer and the end user. Developers must be willing to expand their toolkits to include different levels of development tools, and users must accept that different parts of an application look or act slightly different.

This type of compromise is really not that uncommon. While J.D. Edwards was converting from an AS/400-only package to an n-tier client/server model, it picked certain components to release quickly into the new model while others were delayed. This allowed their AS/400 customers to leverage the power of a client/server application where that model offered unique benefits. It also allowed J.D. Edwards to gain experience with their new architecture before it bet the farm.

As programming languages and development environments start to merge, I anticipate four major impacts on your technology strategies:

First, you should be able to reasonably customize and extend features of your ERP system. To do this your vendor must adhere to friendly object practices. Friendly object practices include making object interfaces public, as SAP has done with its BAPI interface. It also means not changing the object interfaces between versions to eliminate total rewrite fears when the next upgrade hits.

Second, it will become easier to link applications together by bridging between objects. It should not matter what language the programs are written in. This means big applications, like ERP, can continue to use complex and powerful languages even if your IT staff prefers Java or VB. This approach works very well because when programs use objects, creating a link does not require sophisticated techniques or tools. A corporate Intranet is an ideal example of this approach because you can provide a single interface (the browser) to several different applications using an object enabled Web Server language like IIS ASP.

Third, I expect that you will invest more in extensions or add-ons to your packaged applications than stand-alone solutions. I have been hearing ERP packages called backbones more and more. This fits with the idea that you should be able to only use the parts you need and pick and choose the suppliers of those parts. I'm not advocating early 1990s style choose anything/best of breed; instead, I think that compatible products, partnerships, and value-added resellers will become even more popular.

The Y2K Boom

Y2K issues are the 1999 version of Inquisition-era torture devices. Concerned about depth of the problem? It's the Rack for your business. Facing extended testing and patches? Try out the Iron Maiden. Even if you haven't joined in the crusade to eradicate the millennium bug at this point, I hope you are at least aware of your business' potential exposure. As a minimum, you have already identified the handful of applications that simply must work for you to operate. Those things you fix or replace. Everything else is not critical, or is it?

The difference between having just core Y2K compliance and broader functionality could easily be the difference between just barely surviving the crisis and actually making a profit. Even if you don't beat the millennium deadline, the faster you can recover the lost functionality the better the return on your technology investment and the more payback for your business.

These concepts are not startling or even unique to Y2K. They are just more urgent when everything breaks at once. By this date, you have probably given up all hope if you are thinking in terms of traditional program development. There is hope, however, if you can alter your application development methodologies along the lines I explore in this month's Technology Corner.

It is possible to introduce non-core applications very quickly with high levels of functionality. Constraining your developers to use a complex programming language for all of an application will slow your implementation. They should use the powerful tool where it's needed, but not where they can get by with less. Using the right development environment saves time and money.

Since there is no 100 percent right programming environment, you must allow application developers to use multiple tools to right-size the development/deployment platform. If you can accept (and your developers can implement) this approach then you can repair (and expand) your technology functionality by better leveraging your core applications and simplifying application development.

Your non-core applications are important: they will make the difference between staying in business and staying profitable. Assuming the lights are on Monday, 1/3/2000, wouldn't you rather be ready to service your competitor's customers then just struggle to keep yours happy?

Finally, your custom development needs should be met with a family of smaller applications deployed in a variety of ways such as the Web, client/server, or interpreted environment (like MS Access). These programs should not require elaborate design specifications, months of coding, or special administration by your IT department. They should be tools that compliment your business and fit within your existing technology infrastructure. Most importantly, expect them to evolve with small steps and small investments so that you can throw something away if the program becomes redundant. (Just for clarity, it is nearly impossible to develop and deploy even the simplest standalone application for less that $10,000.)

I am not predicting a revolution in computer technology based on objects. That vision was promised a decade ago and has been very slow to materialize. I have seen recent trends towards object standardization and increased industry acceptance of open standards, however. These positive changes are opportunities for you to leverage both your installed technologies and your technology expenditures better.

Back to the top

March 1999, Technology Corner	Hirschfeld Consulting
	Systems Integration/Analysis/Engineering/Development 504-780-7971 and info@h-consulting.com
.
Quick Navigator: Home \| Web DB Demo \| Articles \| Links \| Bio \| Services \| Comments

March 1999, Technology Corner

Hirschfeld Consulting

What Tools Are in Your IT Toolbox?

Plus Sidebars: Technology Background and The Y2K Boom

Technology Background

The Y2K Boom